ShareWare OnLine 2

home *** CD-ROM | disk | FTP | other *** search

/ ShareWare OnLine 2 / ShareWare OnLine Volume 2 (CMS Software)(1993).iso / bbs_soft / sfnl_92.zip / SF11-92.ZIP / SF11-92.TXT

Wrap

Text File | 1992-11-15 | 43KB | 843 lines

╔════════════════════════════════════════════╗ ║ ╟─┐ ║ K E E P I N G I N T O U C H ║ │ ║ ═══════════════════════════════ ║ │ ║ SPITFIRE Monthly Support Newsletter ║ │ ║ for registered SPITFIRE Sysops! ║ │ ║ November 1992 ║ │ ║ Compliments of BUFFALO CREEK SOFTWARE ║ │ ║ Buffalo Creek's BBS * 515-225-8496 ║ │ ║ 38400/19200/9600/2400/1200 Baud ║ │ ║ 2 Nodes ║ │ ║ ║ │ ╚═╤══════════════════════════════════════════╝ │ └────────────────────────────────────────────┘ Edited by Jacque Shipley The Mother Board BBS - (515) 986-3464 - 19200 Baud Sysop Of The Month by Walt Crede Roam This Fertile Land - (515) 288-8755 - 2400 Baud Newly Registered SPITFIRE BBS List by Ann Woltz Other Contributions As Noted ╔═════════════════════════════════════════╗ ║ Notes from the author of SPITFIRE! ╟─┐ ╚═╤═══════════════════════════════════════╝ │ └─────────────────────────────────────────┘ BCSUTI and TNET --------------- There are a number of SPITFIRE Sysops who are using BCSUTI in conjunction with a program named TNET (TNET.ZIP on my board) for the purpose of importing/exporting QWK mail packets into the SPITFIRE message base. This provides a means of exchanging messages with boards utilizing BBS software other than SPITFIRE. I am told that this process works fairly well, however, there seems to be a common mistake being made when making the setup. As I understand it, TNET allows the configuration of the UTI revision which is to be used. Additionally, I understand that the TNET documentation leads the reader to believe that this should be configured as revision 1. WRONG! BCSUTI is a revision 2 UTI. In the event you configure TNET for revision 1 usage, then you will find that the messages exported will have additional lines and messages imported will be missing message lines. BE SURE TO CONFIGURE TNET TO UTILIZE UTI REVISION 2. Thank you! BCSUTI Configuration -------------------- I am advised that there is a normal product discussion of BCSUTI in the RIME SPITFIRE support conference. (I pray that participants will someday learn how much damage is done to a person's reputation and a product's reputation by this 'normal product discussion'. God grant me the serenity to accept the things I cannot change.) I am a bit reluctant to discuss this matter since the information which I have is 2nd and 3rd hand. However, I am hopefully that I will be able to provide some information which may alleviate this 'normal product discussion'. For whatever reason, it appears that there are those who believe that after adding a Message Conference(s) in SPITFIRE they then must use BCSUTI to add the new Message Conference(s) to the BCSUTI configuration. This is correct, however, as I understand it, this is being done improperly (user error rather than product error - I wonder why that is not discussed on mail systems). First, I understand that the Sysop believes the BCSUTI.CFG file must be erased. I have no idea where in the world this idea could have EVER come from but it is NOT true. BCSUTI.CFG DOES NOT NEED TO BE ERASED!!!! Second, I understand that the Sysop (after BCSUTI is finally booted) then properly selects "Add/Edit Conf" but then INCORRECTLY selects "Add <A>ll" rather than CORRECTLY selecting "Add <O>ne". When "Add <A>ll" is selected, then BCSUTI changes ALL "Short Name Descriptions" to the default descriptions. I suspect the user incorrectly thinks that "Add <A>ll" only adds the conferences then not configured. I just reviewed BCSUTI.DOC and this information is clearly set forth in the documentation. We're Still Cleaning Things Up! ------------------------------- The response to our request for help with cleaning up our registered SPITFIRE board list has been GREAT and we appreciate it. There have been a tremendous amount of SPITFIRE Sysops who have replied to our request for help. We really appreciate all the information which was furnished. We recently mailed a final SPITFIRE v3.2 upgrade notice to eligible SPITFIRE Sysops who have not yet upgraded. They were given notice that if they did not reply by November 15, 1992, that we would consider them as inactive and which makes them ineligible to participate in our SPITFIRE FREE upgrade policy. Quite a number has upgraded due to such notice. Those who did not reply will be removed from our various lists and will be marked as inactive in our database. SPITFIRE FREE Upgrade Policy ---------------------------- As most of you are aware, SPITFIRE v3.3 is being developed. This means that we will be mailing the SPITFIRE v3.3 notice and 'upgrade request form'. We want to continue to provide a means of upgrading at no cost to the Sysop. This is important to us. We have always been proud of our FREE upgrade policy while other firms charge more for upgrades than SPITFIRE's original registration fee. Contrary to what some would have you believe, one of the main goals of Buffalo Creek Software is to treat everyone as fairly and honestly as we can. However, there are problems that we have to deal with. The problems are with the FREE upgrade download option. First, many Sysops return their upgrade request form and indicate that they want to utilize the download option. Their copy of SPITFIRE is then compiled and made available for download. The problem is that the Sysop sometimes doesn't make the download for up to 3 to 4 months or some never call to make the download. Believe me, those Sysops are ruining a good thing that the rest of you enjoy. Another problem is the download itself. Some Sysops select YModem-g (the most unreliable protocol to date) to download their copy. Then when the download fails, we have to compile the copy again. Still another problem with the download option is many Sysops apparently do not retain a copy of their of the software on diskette. I think you would be amazed at the amount of Sysops who ask for a new copy of SPITFIRE because they had a disk crash. This would never be necessary if they would only place a backup copy on diskette. When SPITFIRE v3.2 was released we announced that there would be a $20.00 fee charge (which has not been enforced) for anyone asking for a 2nd copy due to a disk crash. This announcement was made in an effort to 'scare' Sysops into making a backup copy. It didn't work. We still get (weekly) requests for another copy of SPITFIRE because of a disk crash (there are other reasons as well). All the problems associated with the download option do not belong to SPITFIRE Sysops. There is also a problem at our end. We will need to add additional nodes so the SPITFIRE Sysop can get logged on to make the download. The only problem that we have with adding additional nodes it the message base. I continue to reply to 35-40 messages a day (believe me, that takes me 3-4 hours a day). If we add more nodes, then there will be more messages. It is humanly impossible for me to answer more messages each day. In fact, I believe that I am telling you the truth if I say that SPITFIRE v3.3 would be already released if I didn't have to answer messages. When I first started work on SPITFIRE v3.3 I asked (in this newsletter) for your cooperation in not asking to beta test, in not asking when the software was finished and in not asking for trivia additions to SPITFIRE. I should have saved my breath since it didn't work. So, as you can see, there are many problems with the download option of our FREE upgrade policy. We absolutely do not want to discontinue the download option but it is starting to appear to be inevitable. HAPPY THANKSGIVING ------------------ We will soon celebrate Thanksgiving. There is no doubt in my mind that we all have many, many things to be thankful for. We seem to live in a world full of hate, destruction and violence. Let's (as SPITFIRE Sysops) pledge to do our part in making our world a much better place to live. Thank you for your continued support and promotion of SPITFIRE. The SPITFIRE project continues to grow at a very nice pace. None of this would be possible without the help of many GREAT SPITFIRE Sysops. It hasn't changed - for the most part, SPITFIRE Sysops are top shelf folks. Thanks. Until next time, may God bless you... Mike, Ann & family ╒═════════════════════════════════════╕ │ SPITFIRE'S EVOLUTION TO VERSION 3.3 │ ╘═════════════════════════════════════╛ Many of you may be following the changes in SPITFIRE by reviewing updates to the WHATSNEW.33 file. However, I thought it might be appropriate to provide a brief description of some of the new features you can expect to see when SPITFIRE Version 3.3 is available. Before you start asking, no release date for V3.3 has been announced but, as always, it will be well worth the wait. Main Menu Enhancements ---------------------- Significant changes have been made to the questionnaire files in SPITFIRE. SPITFIRE can now handle 24 questionnaire files. Previous versions only allowed 9. The questionnaire files have been renamed. They are now called SFORDER<x>.QUE and SFORDER<x>.REP. <x> represents an alpha character from A to Z with the exception of G and Q which are reserved for Goodbye and Quit. Examples would be: SFORDERA.QUE SFORDERA.REP SFORDERB.QUE SFORDERB.REP SFORDERC.QUE SFORDERC.REP SFNEWU.QUE SFNEWU.REP and so on... As before, the QUE represents the questionnaire file and the REP is the file where the replies to the questions are stored. The format of SFORDER.MNU has been modified as well. SFORDER.MNU now uses the following format: <Title of the Questionnaire>,SEC>=x,ONETIME,PRINT The title of the questionnaire can be up to 25 characters and should appear first on the SFORDER.MNU line. The questionnaire title should be followed by a comma. This is followed by the security required to access the questionnaire. The security is defined by SEC<=x or SEC>=x or SEC=x where x represents a numerical value that should coincide with the framework of security levels applicable on your BBS. (Any caller with Sysop security may access a questionnaire regardless of how SEC is defined.) The ONETIME variable is optional and used to limit responses to the questionnaire to one time. If ONETIME does not appear, the questionnaire can be answered multiple times. The PRINT variable is also optional and if present sends the caller's questionnaire responses to the printer. If PRINT is not included on the line, no attempt is made to send the questionnaire answers to the printer. An example of the SFORDER.MNU Questionnaire might look like this: SPITFIRE Orders,SEC>=10,ONETIME Callers with a security of 10 or greater could respond to the questionnaire SPITFIRE Orders one time only. Their responses would not be sent to the printer. Corresponding to this change, when opting to View Log Files either from the "Ready..." prompt or from the Sysop Menu, you now have the option of reading replies to the questionnaire files. The View Log Files has an option <O>...SFORDER<x>.REP. When this option is selected SPITFIRE will prompt for the letter to the corresponding questionnaire file [A..Z]. Next, you are prompted whether to begin reading the file at Today's Date, Beginning of the File, Specify A Date or Quit. If the corresponding log file is not found, SPITFIRE will report this and return to the "Ready..." prompt or to the Sysop Menu. Message Menu Enhancements ------------------------- A new option has been added to the Message Conference Record. You can now toggle a message conference as Read Only. This is done by pressing the asterisk key "*" which toggles the Read Only option from Yes to No. If toggled to No, callers can read and enter messages. If toggled to Yes, messages may be read but no messages can be entered in this conference. SPITFIRE's message option to copy a message never included the option to mark the message as a netmail message when being copied to a netmail conference area. This has been added. Now if a message is copied to a conference which has been configured as a netmail conference, the caller is prompted the same as if the message was being entered directly into the netmail conference (i.e., whether the message should be marked as a netmail message and if so, whether the message should be purged when sent). SPITFIRE has been changed in regard to the 'Purge message after it is sent? [y/N] ' question when a message is marked to be sent out on a mail network. Previously, SPITFIRE asked this question each time a message was marked to be sent. Now, SPITFIRE will not ask this question if 'Caller Message Deletion' is not allowed in the Message Conference. As usual, this does NOT apply to callers with Sysop Security. The SPITFIRE Door option has been removed from the Message Menu. It has been replaced with SPITFIRE Mail System. This option will allow the caller to extract messages for download and to upload replies. This feature uses the .QWK mail format. As is customary with Buffalo Creek Software this feature does not provide a lot of bells and whistles options. If you do not wish to make this option available to your callers, simply set the security to access this option high enough so it is not available. When a caller selects the SPITFIRE Mail System, SPITFIRE will shell to LAKOTA.COM. LAKOTA.COM must reside in your SPITFIRE home directory. It is written in assembler and will handle your .QWK mail transfers. The mail packet, generated when downloading with this option, should work with any .QWK mail reader. SPITFIRE's internal message packing routines have been modified. The Turbo Pascal code that was used to pack the message base has been removed from SPITFIRE. SPITFIRE now shells to SFPCKMSG.COM when packing the message base, either as Event M or from the Sysop menu. SFPCKMSG.COM must reside in the SPITFIRE home directory! In relation with this change, the option Backup Files has been removed when configuring SPITFIRE's Message Conference Records. It has been replaced with Purge Unreceived Messages. If this is set to Yes, when packing the message base any messages older than that configured via the Purge Msgs Older Than option will be purged even if they have not yet been received. If set to No, unreceived messages will not be purged. Similarly, the <M>...Erase SFMSG*.$?? has been removed from the File Removal Menu since it is no longer needed. SFPCKMSG does not make backups of the message conference files. A new feature has been added to the Message Conference Records. This is "Allow Message Routing y/N?". This feature is only applicable to message conferences that have been configured as netmail conferences. When entering a message in a netmail conference, you are prompted as to whether to send the message via netmail, whether it should be purged when sent and now asked "Would you like to route this message? y/N" The default is No. If you respond with a Y, you are next prompted to enter the routing number or name. If you are using BCSUTI ßv1.0, revision 2.8 or greater, the message will automatically be routed for you. If you are using Bob Browne's UTI or earlier version of the BCSUTI you will need to route your messages in the normal fashion. The Routing feature will also work with carbon copy messages making it possible to send the same message to 10 different people, routing it to 10 different locations. SPITFIRE's netmail tagline has been shortened. File Menu Enhancements ---------------------- The option to select SPITFIRE Doors from the File Menu has been removed. It has been replaced with a new option, Shuffle Files. BE SURE TO SET THE SECURITY FEATURE OF THIS OPTION HIGH ENOUGH SO THAT IS NOT AVAILABLE TO YOUR NORMAL CALLERS! What this feature does is allow files to be moved from one File Area to another. When the file is moved, the file name, file size, file date and file description from the original SFFILES.BBS is appended the the SFFILES.BBS of the File Area to which the file is being moved. Files can now be tagged when logged on to the BBS locally. Files may be tagged for erasing or for shuffling from one file area to another. If no files have been tagged and you select either the erase or shuffle option, you will be asked to enter the file name. When you are erasing, you are prompted to verify that you wish to erase the file before it is erased. If you are moving files you will be asked which area to move the file to. You are also given the opportunity to list the file areas or to quit. If you have tagged files and you select to either erase or shuffle the files, the file name you have tagged defaults into the prompt requesting the file name and proceeds the same as if you were entering the file name manually. In other words, if you are erasing tagged files, first you are asked if you wish to erase the tagged files. If you reply with a yes, you are asked to enter the filename but the tagged file name defaults automatically. You are then asked if you are sure you want to erase this file. This continues until all tagged files are processed. If you are shuffling tagged files, when you select S, the 'Enter Name of File' to move prompt appears but the file name from your tagged files defaults in automatically. You then are asked to enter the file area you wish to move the file to. Pressing Enter will list the file areas or you may quit. This continues until all tagged files are processed. The Tag Files For Download has been changed to Tag Files For Use. This clarifies phrasing for local log ons where the files can be tagged for erasing or moving. SPITFIRE now supports bi-directional file transfers. When configuring SPITFIRE to allow bi-directional file transfers, the SFEXTDN.BBS file in the SPITFIRE display path should be modified to include the name of your bi-directional transfer protocol. The title of transfer protocol (which will display to the callers) should be followed by a comma and the term "bi-directional" (without the quotes). As an example, your SFEXTDN.BBS might look like this: <A> Zmodem Single File,UseFile <B> Zmodem Batch,Batch,UseFile <C> HS-Link v1.12 Bi-Directional,Bi-Directional When the ",bi-directional" is found SPITFIRE will automatically assume a batch mode and a usefile mode. In other words, you are not required to include a ",batch" or ",usefile" on the menu line. A new batch file will be called to initiate the bi-directional file transfer process. SFEXTBI<x>.BAT should exist in your SPITFIRE external protocol directory. <x> should match the character by which your caller selects the associated file transfer protocol. In other words, if the bi-directional transfer protocol is option <A> from the menu (SFEXTDN.BBS) the batch file would be named SFEXTBIA.BAT, if the bi-directional transfer protocol is option <E> from the menu (SFEXTDN.BBS) the batch file would be named SFEXTBIE.BAT, etc. In our example above, the file would be named SFEXTBIC.BAT. The contents of our sample SFEXTBIC.BAT file might look like this: @Echo Off HSLINK -P%2 @C:\SF\EXT\SFEXTRAN.LST When a caller selects a bi-directional file transfer, the caller is first prompted to enter the name of the file(s) they wish to download. This follows existing download procedure, i.e., use of file tagging, etc. SF will continue to prompt the caller until no file name is entered. When no file name is entered, the file names selected for download will be displayed to the caller. The caller is next prompted to enter the file name and description of the file(s) to upload. When prompted for a file to upload and none is entered, SPITFIRE then shells to the appropriate SFEXTBI<x>.BAT batch file so that the bi-directional file transfer can begin. With the addition of bi-direction file transfers, the batch menu options were changed slightly. The <U>...Upload Batch Queue was changed to <B>...Begin File Transfer and the <D>...Download Batch Queue was changed to <B>...Begin File Transfer. General Configuration Updates ----------------------------- SPITFIRE will now open the comm port at 115200 or 57600. There have been reports that some of the newer modems send different result messages when an error correction connection occurs. SPITFIRE is now hardcoded to search for ARQ, MNP and REL result codes to indicate that an error correction connection has been made. In addition to these, the SPITFIRE will search for the error correction control message the Sysop has configured using the ALT+M configuration window. A new option is available from the ALT+Z configuration window. This option is Upload Available Disk Space. The Sysop will use this option to configure how much disk space must be available before a caller will be allowed to perform an upload. The default is 100k. When opting to view the caller's records, either from the Sysop Menu or by pressing ALT+A at the 'Ready...' prompt, the caller's passwords are no longer visible. Four astericks appear in place of the caller's password. This is a security feature. By selecting 'P' from the menu, a submenu appears which provides the options to <V>iew, <C>hange, or <Q>uit. Viewing a password, simply displays the password, Change provides the opportunity to modify the password and Quit returns you to the previous menu. Other Updates ------------- In previous versions of SPITFIRE, if operating a multi-node system and one caller on one node was reading a message conference and another caller on another node was saving a message in that same conference, there was a 10 second or so delay in the message being saved. This has been fixed. The shareware version previously allowed for a 30 day or 500 caller trial before the unauthorized copy message would appear. This has been changed to a 30 day trial period only. A noise filter is included which prevents garbage characters from being accepted when a caller enters their name during the log on process. If any of these 'garbage characters' are found in the name, then SPITFIRE just prompts for the name again. This is designed to prevent a new caller named l!Y\&1xzQj2,'54BUP18oT.DYAHYEa/#LR-<.7i~5U3M from logging on. A change has been made to JOKER.DAT. If any line in JOKER.DAT is preceded with '@ ' followed by text, no one with that portion of the text in any part of their name will be allowed to log on to the BBS. This is primarily intended for profane words but for example I will use: @screw The above would deny access to the BBS by anyone with the name of Screw You, Screw It, Screw Up, Screw This Board, etc. This new feature is to be used with caution because it would be extremely easy to unintentionally deny someone access. For example, the above (@screw) would deny someone named Ben Thumbscrew access. Display Files ------------- A new display file has been added, SFONFAIL.BBS/CLR. This is displayed when a caller logs on the BBS and fails to enter the correct password. An example of how this display file might be used would be to inform the caller that perhaps another caller by the same name is already a user of the BBS and that they might want to log on using a nickname or using their middle initial. ╒══════════════════╕ │ THE IRONCLAD BBS │ ╘══════════════════╛ Running a BBS can be a lot of work. Keeping it running reliably can be even more work. Computers are notoriously un-reliable over the long run. But, there are several things you can do to help keep your system running with minimum downtime. Being an electronics engineer puts me in a unique position as a BBS sysop in making my system "iron clad" and able to "take a licking and keep on ticking". Here are a few things I have done to customize my system such that it keeps running regardless of problems. This is often called "Fault tolerance", and can become quite an art. 1) Buy the best computer you can afford for your BBS. My system is provided by, and built by my employer. It is a STD Bus based industrial computer. It is an extremely rugged, reliable system to start with. At least an order of magnitude more reliable than the best desktop systems. However, the cost is an order of magnitude more than the best desktop systems! The CPU card alone costs as much as a complete mid-range desktop system. Not an alternative for most. The bottom line is: Obtain the best hardware you can, this includes the MODEM. 2) Use some kind of watchdog timer. This is the heart of any really fault tolerant system, regardless of function. This can keep your system running when all else fails. If at all possible, use a hardware watchdog. Anyone with a minimum of electronics knowledge can wire-wrap one on a plug-in board in a couple of hours. The output is connected to the computer's RESET line. My setup is such that the hardware timer has a time-out of 18 hours. I have two events set up at 12 hour intervals (3:00 AM and 3:00 PM) to re-start the timer. If the system ever crashes, for whatever reason, the most it will be offline is 18 hours. Then the timer will time-out, and reset the system. The system WILL come back up, unless it is flat broken. The watchdog can serve another purpose. If you have terminated SF to do some kind of maintenance, and are called away from the system, and forget about it, the watchdog will eventually time-out and restart SF for you. Care should be taken in choosing the watchdog interval. A shorter interval will result in less downtime if the system crashes, but it also means that you must restart the timer more often. For example, if you have a two hour watchdog, you would have to have 12 events configured to re-start it. And you could still get into trouble. Say your time limit for users is 1 hour. And let's further say that you re-start the timer in SFLOGON.BAT, when the user logs on. The user spends an hour uploading the source code to NETHACK, a 2 megabyte file. This takes him an hour. The upload compensation on most boards will give him time out past the reset time. Now this user decides to use all this time to download the latest version of Spitfire and some utilities. Somewhere in the middle of this, the timer times out, and the user is history! Not good. You can get around this by declaring your timer restart events as on-time events, but this is tacky, to say the least. I recommend the timer run be 50% longer than the restart interval. 18 hour timer gets restarted every 12, a 12 hour timer gets restarted every 8, etc. I wouldn't recommend anything shorter than 4 hours, and 6 would be better. Real long timers, such as mine do not require restarting when the user logs on, but short ones do. Long timers also allow the luxury of NOT having to declare as many events to restart them, nor do these events have to be on-time events. Be sure to restart your timer when terminating Spitfire or shelling to DOS remotely! Software timers to accomplish the same thing are available. They are not as reliable as hardware timers, but they are far, far better than nothing, and are easier to set up. 3) REBOOT! Once a day, execute a cold boot on your system. I do this automatically. This reloads everything and helps eliminate problems caused by power glitches, "cosmic rays", poorly written programs, Sysop errors, whatever. Buffalo Creek has a simple program that will do this for you, or you can write one with DEBUG. If you are running 4DOS or NDOS, you can use the REBOOT command. I'm very leery of programs running out of RAM for long periods of time, especially dynamic RAM, which 99% of the desktop machines utilize. 4) Use an external MODEM. Lots of Sysops already believe in this one. The problem with MODEMs, especially the newer, smarter variety, is that they can get lost just like the computer can. I have more custom hardware to handle this than is ordinarily available. I actually have computer control of the AC line going to the MODEM. I power cycle the MODEM daily at the same time I do my reboot. I also automatically power down the MODEM when I F10 out of SF, and automatically power up the MODEM in SF.BAT just before actually running Spitfire. Mike Woltz, the author of Spitfire, has also included the ability to correct MODEM problems within Spitfire. Take advantage of this ability! Use a file called BADINIT.BAT to attempt to do something about a MODEM that will not respond to Spitfire. In my case, I turn the power off, delay, and then turn it back on. Has never been known to fail. Others who don't have the luxury of AC control, may attempt to do this through software. Internal Modems may have a reset port, or perhaps automatically resetting the computer via a hardware port may do the trick. 5) Automate, automate, automate! Over the years, Mike Woltz has made significant improvements to Spitfire that allows Sysops the ability to considerably automate their BBS systems. This allows not only a easier to run BBS, but a more reliable one as well. SF can shell to various batch files at various times of execution. Take advantage of this to automate, and bulletproof your systems. I hear tell of systems local to me every day that have been down for days when the Sysop goes out of town and something bad happens. Since I have installed the custom hardware and batch files, etc. my system has had zero downtime, as long as there was power to run it. My system was one of 2, out of about 15 local boards, that came right up and ran immediately after power was restored after the October 17, 1989 Loma Prieta (Or San Francisco to you out of staters) Earthquake. And it hasn't been down since. Since the system is in my office at work, it runs un-attended most of the time and must be able to take care of itself. 6) Buy a UPS? Maybe, if you can afford it. If you do, you must do one of two things: Either you must be near the system at all times to shut it down if the power is down for a long time, or you must buy one of the more expensive units that is capable of communicating with the computer allowing it to eventually turn itself off, if necessary. If you let an ordinary UPS run without shutdown in an extended power outage, you WILL kill it. Frankly, I don't feel it is worth the hassle as most of your local users will probably be without power as well, and the phone lines may be out as well. u]3 Do provide surge protection, etc. if your system doesn't have it built in already. A constant voltage transformer is a nice toy to plug your system in, it doesn't buy you anything in a black out situation, but it regulates the AC going into your system and allows it to keep going in case of brown outs. 7) Shutdown your hard drive. This is one even I haven't implemented, yet. I intend to eventually boot Spitfire off of one of my semiconductor (Flash EEPROM for you techies) disk drives, and turn on the hard drive power in SFLOGON.BAT, and off in SFINIT.BAT. This will cut down drastically on Hard drive wear and tear. This will take considerable planning to ensure that SF has all the files it needs to execute until it can turn on the hard drive. A TSR may be needed to monitor carrier status in order to power up the hard drive sooner. I distrust any mechanical part of a computer system, and try to use mechanics as little as possible. In closing, Spitfire has evolved to the point where it has enough built in capability to both automate, and bullet proof your board. If you have a little hardware/software knowledge, you can really customize your board to the point where nothing will stop it. Even if you don't like to get your hands dirty, you can still do several things to make your board more crash proof. If you need tips on building a watchdog timer, feel free to contact me at Buffalo Creek, or at my board, Hacker Heaven at (408) 375-5455. Article Contributed by Mark Pickerill Sysop, Hacker Heaven BBS ╒════════════════════╕ │ SYSOP-OF-THE-MONTH │ ╘════════════════════╛ Brian Carlson The Chicken Coop Lake in the Hills, Illinois I remember when I saw my first modem. My neighbor bought a 300 bps modem for his Commodore 64 and insisted that it was something that I should add to my Commodore. He was right! I used that Commodore for a year calling various local boards. I was almost immediately inspired to run my own board. In April 1990, I bought an IBM clone with a 20 meg hard drive and a month later I was on-line with shareware SPITFIRE. SPITFIRE was the first and and only BBS software I have ever run. I never looked at any other BBS software because it was obvious SPITFIRE was easy to use and could be made to do exactly what I wanted it to do. The Chicken Coop was born. When I first started running SPITFIRE in its evaluation mode, I jokingly named the board "The Chicken Coop." I live inside village limits and for years I have had a pet chicken. She was the subject of many jokes and comments with the people I communicated with via my modem. When I registered SPITFIRE, I decided to get "serious," decided I wanted to change the board's name to something more sophisticated. Immediately about 30 callers objected, every one complaining that they liked the old name. And it's been The Chicken Coop ever since. The Chicken Coop has come a long way since its beginning. I'm now a member of RelayNet mail network and this year upgraded to a 14.4K V32bis modem. The old 286 motherboard was replaced with a 386 and enough memory for a second node sometime in 1993. The main theme of my board is RelayNet and on-line games. I run several monthly contests, having prizes ranging from higher access for a month to an exclusive private log-on time for the month's number one winner. I use SPITFIRE's on-time event feature to configure the board as a private BBS for a 15 minute period allowing the month's winner a "no-busy-signal" log-on time once a day. This is a prize costing the sysop nothing but is of great value for the callers due to the busy nature of my board. In closing, I want to thank Mike Woltz for writing a great, easy- to-use software, Richard Johnson of the Byrd's Nest BBS for technical assistance and making the switch to a high speed modem a breeze, and to John Krone of ICIX BBS for helping me with Spitfire in the early days. Also, I would like to thank Spitfire Chicago Area Sysops Association <SFCASA> for support, friendship and some nice parties! SFCASA can be reached at The Chicago Megaphile BBS. ╒════════════════════════════════════╕ │ NEWLY REGISTERED SPITFIRE SYSTEMS │ ╘════════════════════════════════════╛ A hearty welcome is extended to the following, who have recently become public registered SPITFIRE Bulletin Board Systems: The Abacus...................................717-633-7232....2400 Baud John Pittman, Sysop..............................Hanover, Pennsylvania The Runesword BBS...........................707-526-4969..Unknown Baud Lyle Barrow, Sysop..............................Santa Rosa, California The Toolbox BBS..............................502-942-1111...14400 Baud Charles Baker, Sysop...............................Fort Knox, Kentucky Joshua.......................................1-39-534-797...14400 Baud Ribau Frederic, Sysop...............................Versailles, France Wolfpack.....................................502-942-8041...14400 Baud Pablo Quirindongo, Sysop...........................Muldraugh, Kentucky The Crystal Ball.............................502-271-2500....2400 Baud Brett Morris, Sysop..................................Herndon, Kentucky We Be Games..................................206-475-0708....2400 Baud David Stepp, Sysop..................................Tacoma, Washington Hog On Ice BBS...............................916-424-8308...14400 Baud Nick McGee, Sysop..............................Sacramento, California The Last Chance..............................614-522-2829....2400 Baud Charles Brand, Sysop.......................................Heath, Ohio The Home Front BBS...........................502-942-0089....2400 Baud Michael Harrington, Sysop..........................Fort Knox, Kentucky Moiraine's Playground.......................817-542-5579....9600 Baud Dorothea Hoelzl-Eyster, Sysop.....................Copperas Cove, Texas The Jungle's Vine............................606-441-6998....2400 Baud Della Halpin, Sysop..............................Fort Thomas, Kentucky The Scrabbler................................604-360-0261....2400 Baud Joan Gilkin, Sysop..................Victoria, British Columbia, Canada Cosmic Room Service...........................902-569-5870...2400 Baud Richard Lidstone, Sysop............................Keppoch, PEI,Canada Moonlite.....................................317-966-3933....2400 Baud David Mull, Sysop....................................Richmond, Indiana The Cess Pool................................708-352-9231...14400 Baud Rick Gross, Sysop...................................LaGrange, Illinois Milo's New Power Generation BBS...............302-328-5557...2400 Baud Randall Callahan, Jr., Sysop......................New Castle, Delaware Sky Data.....................................616-684-3688...14400 Baud Randy Rentz, Sysop.....................................Niles, Michigan Sawbuck's....................................717-632-2788....9600 Baud Thomas Miller, Sysop.............................Hanover, Pennsylvania The Future BBS...............................717-426-3173...14400 Baud Brian Sracic, Sysop..............................Maytown, Pennsylvania Deranged BBS.................................305-936-1164....9600 Baud Jeffrey Snyder, Sysop...............................Adventura, Florida Clown N' Around..............................405-685-5184....2400 Baud William Dodson, Sysop..........................Oklahoma City, Oklahoma The Falls BBS................................714-794-8112....2400 Baud Robert Wise, Sysop............................Forest Falls, California Desert Sands.................................915-594-1280....2400 Baud Steve Simon, Sysop......................................El Paso, Texas Desert Nights BBS............................602-578-3589....2400 Baud Mark Slaughter, Sysop..................................Tucson, Arizona Bytewise.....................................317-996-4065....2400 Baud John Hobson, Sysop................................Mooresville, Indiana The Terre Haute Music BBS....................812-235-1692...14400 Baud Bob Braun, Sysop..................................Terre Haute, Indiana The Fhunny Pharm.............................713-474-5420...12000 Baud Rick Bedard, Sysop.....................................Seabrook, Texas Networkers Box.............................+49-6051-12854...14400 Baud Thomas Hofmann, Sysop.......................D - 6466 Gruendau, Germany Two Amigos BBS...............................806-352-7455...14400 Baud Greg Vincent, Sysop....................................Amarillo, Texas "FAITH" Full BBS.............................203-747-4813....2400 Baud Roger Barker, Sysop............................Plainville, Connecticut The Light House BBS..........................207-499-2696....2400 Baud Deron Treadwell, Sysop....................................Lyman, Maine The Computer Clinic..........................401-421-3452...14400 Baud Dave Manchester, Sysop........................Providence, Rhode Island Howl!........................................713-862-1415...14400 Baud Joel Harris, Sysop......................................Houston, Texas In addition, there were 4 new private SPITFIRE BBS Systems registered. These private SPITFIRE BBS's included registrations from: Rialto, California; Sunnyvale, California; Tempe, Arizona; and Houston, Texas. There were 25 registrations for whom registration information was incomplete. These included BBS's in: Fresno, California; Arlington, Texas; Clinton, Indiana; Providence, Rhode Island; West Monroe, Louisiana; Palmer, Arkansas; San Antonio, Texas; Chicago, Illinois; Nikiski, Arkansas; Wallaceburg, Ontario, Canada; Bethany Beach, Delaware; Asan, Guam; Houston, Texas; Pt. Pleasant, Pennsylvania; New Orleans, Louisiana; Exeter, Rhode Island; Weehawken, New Jersey; Garland, Texas; FPO Address; Topeka, Kansas; Forestville, California; Norristown, Pennsylvania; Houston, Texas; Labrador City, NF, Canada; and Waterloo, Ontario, Canada. The increase in registrations where information is incomplete is largely due to Buffalo Creek's Software's new policy of accepting on-line Mastercard and Visa credit card registrations. JUST A REMINDER...the newsletter is always looking for contributions! Please forward any articles in ASCII text to either Buffalo Creek's BBS or The Mother Board BBS.